Wireless communication is today a key component of mobile devices. Multiple devices part of a wireless network must sometimes be synchronized in order to make transmitted time-related data meaningful. This is, for example, the case when audio data is sent wirelessly to multiple devices and must be outputted at the same time.
By default, the local clocks of the devices in the wireless network are completely unrelated as they are derived from clock signals produced by different clock generators. A clock generator is a hardware oscillator, usually a crystal oscillator, although simpler tank circuits and even RC circuits may be used. The angular frequency of the hardware oscillator determines the rate at which the local clock runs.
All local clocks are subject to a clock drift, also called clock skew; oscillator frequency will vary unpredictably due to various physical effects. So, two local clocks issued from two wireless devices differ not only from a relative offset, being the difference of the offsets of each local clock compared to real time, but also from a relative drift. Equalizing just the instantaneous values (correcting the offsets) of clocks is not enough for synchronization since the local clocks will drift away afterwards.
Therefore, a synchronization scheme should either equalize the clock rates as well as offsets, or it should repeatedly correct the offsets to keep the clocks synchronized over a time period.
The above definition of synchronization actually defines the strictest form of synchronization, where one seeks perfect matching of time on different clocks, but this definition can be relaxed to different degrees according to the needs of an application.
Multiple techniques have been developed to solve this issue. The Network Time Protocol (NTP) is a networking protocol for clock synchronization that is used by all internet infrastructure. A simplified version, Simple Network Time Protocol (SNTP), has been developed for simple applications. The Precision Time Protocol (PTP) is a protocol that is used to synchronize clocks in a Wireless Local Area Network (WLAN). Many other techniques exist such as Time-sync Protocol for Sensor Networks (TPSN) or Flooding Time Synchronization Protocol (FTSP). All these techniques rely on sort of message exchange between the devices and are advantageous as they do not rely on a particular wireless protocol.
Multiple wireless protocols have been created, such as Wi-Fi or Bluetooth, using different spread spectrum techniques to achieve larger bandwidth. Some of them, like Bluetooth, use fast Frequency Hopping Spread Spectrum (FHSS): the carrier is rapidly switched among many frequency channels using a pseudorandom sequence known to both transmitter and receivers. This inherently requires that both transmitter and receivers share a common clock. In Bluetooth, a network of multiple devices is called a piconet and this clock is the Bluetooth piconet clock. This clock is used to schedule the transmission of packets over the piconet.
In the Bluetooth standard, every Bluetooth device has a Bluetooth reference clock (noted CLKR in the standard), which is driven by the free running system clock. The free running system clock, which is the controller clock, corresponds to the free running clock of the processor on which the controller runs (for instance a quartz clock). Every Bluetooth clock also has a Bluetooth native clock (noted CLKN in the standard) which is defined from the Bluetooth reference clock CLKR by adding an offset (noted time_based_offset in the standard). The so-called “Bluetooth clock” (or “Bluetooth piconet clock”, noted CLK in the standard) corresponds to the Bluetooth native clock CLKN of the master of the piconet. This Bluetooth clock is shared between all the Bluetooth devices of the piconet and used for transmitting and receiving data packets. More specifically, for each device of the piconet except the master (i.e. all the sink devices), an offset (noted slave_offset in the standard) is added to its Bluetooth native clock so that its Bluetooth clock (equal to its Bluetooth native clock plus the offset) corresponds to the master's Bluetooth native clock (i.e. the Bluetooth piconet clock). In the following, for the sake of clarity, the wording “Bluetooth piconet clock” is used to designate the Bluetooth native clock of the master, the wording “Bluetooth clock” of the master device is used to designate the Bluetooth native clock of the master device, and the wording “Bluetooth clock” of a sink device is used to designate the result of adding an offset to the Bluetooth native clock of the device.
The Bluetooth clocks of the sink devices involved in the piconet are periodically resynchronized with the Bluetooth piconet clock. The reason is that, during normal operations, the reception of a packet, defined at a certain Bluetooth tick, must take place in a window length of 20 μs, which allows the packet to arrive up to 10 μs too early or 10 μs too late.
This behavior is exemplified in relation of FIG. 10. For instance, if a packet 1001 is received at a time t1 while it was expected to be received at a time t2, the Bluetooth clock of the sink device may be resynchronized by modifying the slave offsets according to the time elapsed between t1 and t2. Indeed, the time at which the packet should be received is well defined in the standard and is aligned with the Bluetooth piconet clock. Any signal/packet that is expected to be received on a Bluetooth piconet on a specific time (as described here) may be a piconet-synchronized signal in the language of the claims.
In addition, each Bluetooth device has a respective local clock, which is dedicated to some applications, including applications relative to the audio content (for instance, the local clock of a slave is used for playing audio data).
The common clock (i.e. Bluetooth piconet clock) that is shared by the transmitter and the receivers could be used to synchronize the local clocks of the Bluetooth devices part of the piconet. However, this information is only available in the controller stack, the part of the protocol stack that contains the timing critical radio interface. The second part of the protocol stack, the host stack, that deals with high level data, does not have access to the timing information with an accuracy that is good enough for use cases such as audio synchronization.
Indeed, the host stack only has access through the Host Controller Interface (HCI) to a method HCI_Read_Clock that returns the value of the Bluetooth piconet clock in ticks in an asynchronous Command Complete event. Because one tick of the Bluetooth clock is equal to 312.5 μs and because the HCI is asynchronous and thus subject to huge delays depending of the chip activity (if there is a heavy packet traffic, the command will be delayed a lot), the values returned by simultaneous HCI_Read_Clock on the devices of the piconet can vary from several milliseconds.
The controller stack is generally implemented in a low-cost silicon device containing the Bluetooth radio and a microprocessor. The host stack is generally implemented as part of an operating system, or as an installable package on top of an operating system. For integrated devices such as Bluetooth headsets, the host stack and controller stack can be run on the same microprocessor to reduce mass production costs. In all cases, the host stack runs on the same processor as the application layer and interacts with it. So, because the values of the timing reference retrieved by the host stack can vary from several milliseconds, the synchronization of the local clocks is subject to the same variations.
Synchronizing precisely local clocks is particularly important for instance in the context of wireless audio loudspeakers communicating with an audio source device via a Bluetooth protocol. In particular, desynchronization between two earbuds (or similar) may be inconvenient for the user even if the desynchronization is not greater than 300 μs.
By “loudspeaker”, it is meant any electroacoustic transducer, which converts an electrical audio signal into a corresponding sound. The term “loudspeaker” includes for instance audio speakers of a stereo system, headphones, earbuds, hearing aids, etc. The audio source device (or simply “source device”, or “source”) may be, for instance, a mobile phone, a portable game player, a portable media player, a computer, a tablet, a television, a control device of a stereo system, etc. In the following, the source device may also be referred to as “control device” (which is different from the “controller”).
In the prior art, many solutions have been proposed to overcome a proper rendering of audio on two or more sinks devices and these solutions are described below.
In first wireless loudspeaker systems of the prior art, the loudspeakers communicated with an audio source device via a wireless communication protocol, such as Bluetooth or Wi-Fi, but were connected to each other by a wired link. Typically, these systems used a single radio frequency (RF) transceiver to deliver audio to separate loudspeakers via the wired link.
In the past few years, some solutions have been implemented to avoid such a wired connection between the loudspeakers. These solutions may concern systems in which the loudspeakers are earbuds, in the number of two (left and right).
One solution consists in a chained connection between the source, the first earbud and the second earbud, as represented in FIG. 1a. The wireless audio system of FIG. 1a comprises an audio source device 101, a first earbud 102 and a second earbud 103. For instance, the first earbud 102 may correspond to the left earbud and the second earbud 103 may correspond to the right earbud.
The first earbud 102 is connected to the source device 101 according to a first wireless link 104. Typically, the wireless link 104 is a Bluetooth link using the Advanced Audio Distribution Profile (A2DP) constructed from several layers defined by the Bluetooth standard. A stereo stream 105 including packets incorporating stereo data for both left and right channels is transmitted from the source device 101 to the first earbud 102. The first earbud 102 is configured: (i) to play only the audio data relative to one of the two channels (for instance, the left channel); and (ii) to send the mono audio data 106 relative to the other channel to the second earbud 103, via a second wireless link 107.
Typically, the second wireless link 107 may be a Bluetooth link (for instance, True Wireless Stereo), or a Near Field Magnetic Induction (NFMI) link. The second wireless link 107 may also be used for exchanging some synchronization parameters between the two earbuds 102 and 103.
Another solution consists in a wireless link from the source device to one of the two earbuds, while the other earbud is configured to “sniff” (or “snoop”) the wireless link, as represented in FIG. 1b. The wireless audio system of FIG. 1b comprises an audio source device 101, a first earbud 108 and a second earbud 109. As it has been recited above, the first earbud 108 may correspond to the left earbud and the second earbud 109 may correspond to the right earbud.
The first earbud 108 is connected to the source device 101 according to a first wireless link 110. Typically, the wireless link 110 is a Bluetooth link using the Advanced Audio Distribution Profile (A2DP). A stereo stream 111 including one or more packets incorporating stereo data for both left and right channels is transmitted from the source device 101 to the first earbud 108.
On the other hand, the first earbud 108 is connected to the second earbud 109 according to a second wireless link 112 (a Bluetooth link for instance). The first earbud 108 and the second earbud 109 can exchange some parameters, including sniffing/decoding parameters 113 for allowing the second earphone to sniff the first link 110 and to retrieve the audio data relative to the right channel. However, no audio data is exchanged via the second link 112. According to this solution, the second earbud 109 is not connected to the source device 101, and is configured to sniff the first wireless link 110.
However, these solutions have drawbacks.
For instance, according to these solutions, a wireless link between the two earbuds is required (i.e. an additional transmitter chip can be required and it may increase the cost of these earbuds). In addition, such link may suffer from transmission instabilities, partly because the head is effective in blocking radio waves propagation. Furthermore, the wireless link between the two earbuds leads to an increase in battery consumption, especially when it is used to retransmit audio data. In addition, it is necessary to wait for the second earbud to receive the audio data and/or the sniffing parameters from the first earbud, which may cause latency of the system.
Furthermore, these solutions require that the two earbuds be paired together, which limits the possibilities of controlling the two earbuds independently from each other.
There also are solutions of the prior art for controlling a plurality of Bluetooth devices (also called “sink devices”) from a source device by creating a point-to-multipoint link between the source device and the plurality of sink devices, even though this is not initially provided by the Bluetooth standard.
In the Bluetooth standard, audio transmission is defined by the Advanced Audio Distribution Profile (A2DP). The A2DP profile is based on the Audio/Video Distribution Transport Protocol (AVDTP) building block which defines the procedures between Bluetooth devices for establishing the audio stream, negotiating the audio stream parameters and transmitting the audio stream data. According to the AVDTP, an audio stream must be established between two Stream End Points (SEPs).
A SEP represents the resources and capacities of a device. For example, a device such as a portable telephone may have three SEPs, one representing its video receiver capacities, another representing its audio receiver capacities with an SBC codec and a last representing its audio receiver capacities with an aptX codec. Each codec must be associated with a SEP that is different from that or those to which one or more codec(s) is or are associated, but a same codec can be associated with several SEPs.
A limitation imposed by the AVDTP according to the Bluetooth standard is that when a stream has been negotiated between two SEPs, these two SEPs must be locked to each other to deliver it. A used SEP cannot be part of another stream. Switching to a new stream is typically done by terminating the previous one (such as current social modes).
A solution for controlling a plurality of Bluetooth devices (also called “sink devices”) from a source device is to create several Source Stream End Points (SEPs) in the source device controlling chip. A distinct Source SEP may be generated for each Sink SEP to establish one audio stream between the source device and each sink device. For example, and for this implementation, it is referred to application EP17182123.4, which proposes a Bluetooth chip configured to implement a modified A2DP profile so as to create such point-to-multipoint link. According to this solution, a single Bluetooth chip can be used to control several Bluetooth multimedia devices. The A2DP profile is modified without violating the Bluetooth standard, so that interoperability is preserved and the Bluetooth functions are normally supported.
According to such solution, it is possible to transmit respective audio packets from the master device to each of the sink devices, the master device and the sink devices therefore belonging to a same piconet.
Audio packets may be timestamped on the master side using the local clock of the master device and sent to respective sink devices. On the sink device side, the timestamps may then be used to play the received audio data at the right time.
If no reliable synchronization is performed, it is possible that each sink device has a different value of its local clock and thus the sink devices are not able to play a sound timestamped packet at the same time, i.e. the time of the timestamp of the received packet.
There is thus a need for an efficient synchronization method for a wireless system, in particular a wireless audio system in which the loudspeakers can receive and play audio data without suffering desynchronization that might be inconvenient for the user.
The invention aims to provide a reliable synchronization method between a host clock and a controller piconet synchronized signal in order to achieve a global synchronization of the local clocks of the Bluetooth devices of the piconet.